IBIS Macromodel Task Group Meeting date: 10 oct 2006 Members (asterisk for those attending): * Arpad Muranyi, Intel Corp. * Barry Katz, SiSoft * Bob Ross, Teraspeed Consulting Group * Doug White, Cisco Systems * Hemant Shah, Cadence Design Systems Ian Dodd, Mentor Graphics * Joe Abler, IBM John Angulo John Shields, Mentor Graphics Ken Willis, Cadence Design Systems * Kumar, Cadence Design Systems * Lance Wang, Cadence Design Systems * Michael Mirmak, Intel Corp. * Mike LaBonte, Cisco Systems Paul Fernando, NCSU * Randy Wolff, Micron Technology * Richard Ward, Texas Instruments Sanjeev Gupta, Agilent Shangli Wu, Cadence Todd Westerhoff, Cisco Systems Walter Katz, SiSoft Vuk Borich, Agilent * Vikas Gupta, Xilinx ------------- Review of ARs: - Richard see if Xilinx can join us. Vikas Gupta joined us today from Xilinx and spoke about their interest in this group. -done - Macro Library Documentation No discussion on this AR this week. - VHDL library was posted to website (Mike Labonte). -done - Kumar to write up API proposal in a more formal way so boundaries and function partitioning could be discussed more productively. Kumar discussed API proposal in more detail today, discussion below. ------------- New Discussion: Michael Mirmak opened this discussion by briefing us on an announcement for a ballot in IEEE 1076C. This concerns possible API extensions to VHDL, although only for "digital" VHDL. This seems to be a decent fit for what we've been talking about in this group. It was mentioned that these types of things typically get wrapped into AMS in the next revision of the reference manual, if voted in. Arpad noted that there was just recently a revision, and it may be quite a while before the next one. Some concern that we have missed a deadline in this sense. Michael propsed a question to the group: If there is an API rolled into AMS, could that satisfy our requirements, as we've been talking about for IBIS? AR: Michael will try to get access to the IEEE document they are voting on. He will check into access restrictions first. If we get access to it, we will need a couple of volunteers to read the document and see if it is worth our while. It was mentioned that we need to see if this would work for Verilog as well. Vikas Gupta of Xilinx was introduced to the group by Richard Ward. Vikas conveyed Xilinx's interest in the general idea of an API and their interest in how it could work with their existing Matlab infrastructure. Vikas plans to attend this meeting on a regular basis going forward. Joe Abler reiterated his concern about the divide-and-conquer approach. He stated IBM is not going down the path of modeling all of the nonlinearities of the I/O in a circuit-level model. IBM does extract input- and output-parasitics which eventually go into the channel model. Arpad restated the original assumptions concerning the divide-and-conquer approach, namely that this approach is based upon the pulse response, and that the pulse response could be obtained with various existing techniques; this pulse response could then be fed into a post-processing or signal processing block. Joe asked about the intended use of the models (they could be used for generating the pulse response alone). Richard Ward expressed some concern about how crosstalk, and the timing/phasing of it, could be handled in this divide-and-conquer approach and that it is extremely important at these high frequencies. Kumar responded that in pulse-response scenario, crosstalk impulse responses are taken into account as well. Then the simulator could handle these responses as desired. Arpad asked a quesion about the impulse responses and whether they really should only include the passive portion of the system. Kumar responded that if the V-I curves are indeed linear, then the I/O could be included in the impulse response. Arpad wondered whether the V-T curves where important from a waveshape perspective. Kumar thought that they weren't necessarily, since most SerDes should be Linear and Time-Invariant, then a RAMP statement should suffice to describe it. This makes it easier to fit into the IBIS framework. Kumar presented the API proposal (powerpoint presentation): RX_INIT: Basically this is an initialization call for the Algorithmic Modeling Unit. The Algorithmic Modeling Unit can modify waveforms, or impulse responses, and send them back to the existing infrastructure. RX_GETWAVE: Used to actually pass waveforms to the Algorithmic Modeling Unit. This cannot happen until after RX_INIT successfully completes. Essentially, the model talks to the EDA system through the API. It modifies waveforms, extracts recovered clock information. The model creator would have the flexibility to either modify waveforms on the RX_INIT call, or if there are sophisticated equalization algorithms being modeled, then do the modification on RX_GETWAVE. The EDA system can, once it gets the clock information and the modified waveform back from the model, display effective eye patterns, bathtub curves, etc.. AR: Mike to post this powerpoint presentation to the website. Arpad would like more concrete ideas about how IBIS could be changed to accommodate this, if this is indeed what we want t pursue. Presently, Lance and Kumar are creating a BIRD proposal, and plan to present it to the group soon. Arpad would like to see ASAP, even if not polished...just wants the main ideas. Hemant wondered whether he could present their high-level specification for this, which would include descriptions of model calls, interactions between software entities, etc.. Arpad would rather they focus on the BIRD for now, and presenting an early version to the group as soon as possible. ------------- Next meeting: Tuesday 17 Oct 2006 12:00pm PT